Skip to content

Conversation

@Manishearth
Copy link
Member

Progress on #7080

@Manishearth Manishearth requested a review from a team as a code owner October 17, 2025 22:29
@Manishearth Manishearth requested a review from sffc October 17, 2025 22:58
sffc
sffc previously approved these changes Oct 18, 2025
CHANGELOG.md Outdated
- Fix `und-SA-u-ca-islamic` (unicode-org#6736)
- Add RataDie::in_well_behaved_astronomical_range(), use to avoid panics (unicode-org#6876)
- Improve some Gregorian calendar code (unicode-org#6870)
- Fix Hebrew MonthDay resolution with M05L (unicode-org#6966)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: We don't need to document fixes on previous larger changes. If you want you can move this link to be in the list of links of try_from_fields.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I just didn't pick up on the fact that this was MonthDay

- Modifier_Combining_Mark
- `icu_segmenter`
- Experimental (internal) code for convolutional neural network segmenter (unicode-org#6877)
- `icu_time`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought: I'm happy that our splitting out this stuff from the icu_calendar crate helps organize the changelog better.

@Manishearth Manishearth merged commit 79316c2 into unicode-org:main Oct 18, 2025
30 checks passed
@Manishearth Manishearth deleted the clog branch October 18, 2025 06:52
- `icu_calendar`
- Fix `und-SA-u-ca-islamic` (unicode-org#6736)
- Add `Date::try_from_fields` for flexibly building Temporal dates (unicode-org#6910)
- (unstable) Implement date arithmetic according to Temporal specification (unicode-org#6992, unicode-org#7012)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather not advertise unstable code in the change log

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually, yes, but this is a very important thing about this release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and we can directly communicate it to clients that need it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm? We have always advertised improvements to experimental code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(a) This is an API that has been experimental but unchanged for a long time and we're changing it, which is worth advertising

(b) this API is something near stabilization and advertising it to get additional user feedback is valuable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants